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PPP over ISDN 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 
This document describes the use of PPP over Integrated Services 
Digital Network (ISDN) switched circuits. 


This document is the product of the Point-to-Point Protocol Working 
Group of the Internet Engineering Task Force (IETF). Comments should 
be submitted to the ietf-ppp@merit.edu mailing list. 


Applicability 


This specification is intended for those implementations which desire 
to use the PPP encapsulation over ISDN point-to-point links. PPP is 
not designed for multi-point or multi-access environments. 


"It is clear that there is never likely to be a single, monolithic, 
worldwide ISDN." [3] The goal of this document is to describe a few 
common implementations, chosen from the current wide variety of 
alternatives, in an effort to promote interoperability. 
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1. Introduction 


PPP was designed as a standard method of communicating over point- 
to-point links. Initial deployment has been over short local lines, 
leased lines, and plain-old-telephone-service (POTS) using modems. 
As new packet services and higher speed lines are introduced, PPP is 
easily deployed in these environments as well. 


This specification is primarily concerned with the use of the PPP 
encapsulation over ISDN links. Since the ISDN B-channel is by 
definition a point-to-point circuit, PPP is well suited to use over 
these links. 


The ISDN Primary Rate Interface (PRI) may support many concurrent B- 
channel links. The PPP LCP and NCP mechanisms are particularly 
useful in this situation in reducing or eliminating hand 
configuration, and facilitating ease of communication between diverse 
implementations. 


The ISDN D-channel can also be used for sending PPP packets when 
suitably framed, but is limited in bandwidth and often restricts 


communication links to a local switch. 


The terminology of ISDN can be confusing. Here is a simple graphical 
representation of the points used in subsequent descriptions: 


These elements are frequently combined into a single device. 


2. Physical Layer Requirements 
PPP treats ISDN channels as bit or octet oriented synchronous links. 
These links MUST be full-duplex, but MAY be either dedicated or 
circuit-switched. 
Interface Format 
PPP presents an octet interface to the physical layer. There is 


no provision for sub-octets to be supplied or accepted. The octet 
stream is applied primarily at the R or T reference points. 
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Transmission Rate 


PPP does not impose any restrictions regarding transmission rate, 
other than that of the particular ISDN channel interface. 


Control Signals 


PPP does not require the use of control signals. When available, 
using such signals can allow greater functionality and 
performance. Implications are discussed in [2]. 


Control signals MAY be required by some of the framing techniques 
described, and is outside the scope of this specification. 


Encoding 


The definition of various encodings and scrambling is the 
responsibility of the DTE/DCE equipment in use, and is outside the 
scope of this specification. 


While PPP will operate without regard to the underlying 
representation of the bit stream, lack of standards for 
transmission will hinder interoperability as surely as lack of 
data link standards. The D-channel LAPD interface requires NRZ 


encoding at the T reference point. Therefore, as a default, it is 
recommended that NRZ be used over the B-channel interface at the T 
reference point. This will allow frames to be easily exchanged 


between the B and D channels. 


When configuration of the encoding is allowed, NRZI is recommended 
as an alternative in order to ensure a minimum ones density where 
required over the clear B-channel, with caveats regarding FCS [2]. 


Historically, some implementations have used Inverted NRZ (merely 
switching the sense of mark and space), in order to ensure a 
minimum ones density with bit-synchronous HDLC. The use of 
Inverted NRZ is deprecated. 


Automatic Detection 


Implementations which desire to interoperate with multiple 
encodings MAY choose to detect those encodings automatically. 
Automatic encoding detection is particularly important for 
Primary Rate Interfaces, to avoid extensive pre-configuration. 
Only simple encodings are currently distinguished. 


The only reliable method of detection available is to switch 
modes between the supported encodings. Transmission of the LCP 
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3- 


Configure-Request SHOULD be tried twice for each mode before 
switching in rotation. This ensures that sufficient time is 
available for a response to arrive from the peer. 


Max-Configure MUST be set such that the cumulative attempts 
result in no more than 59 seconds of time before disconnect. 
It is preferable that the usual limit of 30 seconds be 
observed. 


Prior Configuration 


By prior configuration, PPP MAY also be used with other 
encodings. Because of difficulty distinguishing them, it is 


not recommended that these encodings be automatically detected. 


Terminal adapters conforming to V.120 [4] can be used as a 
simple interface to workstations. Asynchronous HDLC framing 


[2] is accepted at the R reference point. The terminal adapter 


provides async-sync conversion. Multiple B-channels can be 


used in parallel. Unfortunately, V.120 has a framing mode of 


its own for rate adaptation, which is difficult to distinguish 


from Frame Relay, and which can confuse in-band frame 
detection. V.120 is not interoperable with bit-synchronous 
links, since V.120 does not provide octet-stuffing to bit- 


stuffing conversion. Therefore, V.120 is deprecated in favor 


of more modern standards, such as "PPP in Frame Relay". 


The "Bandwidth On Demand Interoperability Group" has defined 
proposal called BONDING. Multiple B-channels can be used in 
parallel. BONDING has an initialization period of its own, 
which might conflict with the simple detection technique 
described above, and requires extensive individual 


a 


configuration in some current implementations when multiple B- 


channels are involved. It is recommended that the PPP Multi- 


Link Procedure be used instead of BONDING. 


Framing 


For B-channels, in the absence of prior configuration, the 


implementation MUST first use bit-synchronous HDLC [2], as opposed 
other framings, for initial link establishment. This assumes that 
circuit-switched communications are generally [host | router] to 
[host | router]. 


By prior configuration, octet-synchronous HDLC [2] is recommended 
where the network termination equipment interfaces directly to the 
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reference point, and octet boundaries are available at the time of 
framing. Such equipment is likely to be highly integrated, and the 
elimination of bit-synchronous hardware can reduce the part count, 
resulting in lower cost interfaces and simpler configuration. 
Octet-synchronous HDLC MUST be used with NRZ bit encoding. 


For D-channels, by default no data service is expected. By prior 
configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be 
used. 


Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally 
distinguishable, multiple methods of framing SHOULD NOT be used 
concurrently on the same ISDN channel. There is no requirement that 
PPP recognize alternative framing techniques, or switch between 
framing techniques without specific configuration. 


4. Out-of-Band signaling 


Experience has shown that the LLC Information Element is not reliably 
transmitted end to end. The deployment of compatible switches is too 
limited, and the subscription policies of the providers are too 
diverse. Therefore, transmission of the LLC-IE SHOULD NOT be relied 
upon for framing or encoding determination. 


No LLC-IE values which pertain to PPP have been assigned. Any other 
values which are received are not valid for PPP links, and can be 
ignored for PPP service. 


As an alternative administrative measure, multiple directory numbers 
can point to the same physical access facility, by binding particular 
services to each directory number. The called party identifier has 
proven to be reliably provided by the local switch. 


When a called party identifier is used, or when a future LLC-IE value 
is assigned to PPP and the PPP value is received, if the LCP has not 
had the administrative Open event, the call MUST be rejected. 
Receivers MUST NOT accept an incoming call, only to close the circuit 
or ignore packets from the circuit. 
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Configuration Details 
The LCP recommended sync configuration options apply to ISDN links. 
The standard LCP sync configuration defaults apply to ISDN links. 


The typical network feeding the link is likely to have a MRU of 
either 1500, or 2048 or greater. To avoid fragmentation, the 
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT 
exceed 1500, unless a peer MRU of 2048 or greater is specifically 
negotiated. 


Instead of a constant value for the Restart timer, the exponential 
backoff method is recommended. The Restart Timer SHOULD be 250 
milliseconds for the initial value, and 3 seconds for the final 
value. 


Implementations that include persistent dialing features, such as 
"demand dialing" or "redialing", SHOULD use mechanisms to limit their 
persistence. Examples of such mechanisms include exponential 
backoff, and discarding packet queues after failure to complete link 
establishment. In some implementations, discarding the transmit 
queue can temporarily remove the stimulus to retry the connection. 


Security Considerations 


Security issues are not discussed in this memo. 
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